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Abstract 


Many transport services require that user traffic, in the form of 
Pseudowires (PWs), be delivered via either a single co-routed 
bidirectional tunnel or two unidirectional tunnels that share the 
same routes. This document defines an optional extension to the 
Label Distribution Protocol (LDP) that enables the binding between 
PWs and the underlying Traffic Engineering (TE) tunnels. The 
extension applies to both single-segment and multi-segment PWs. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7965. 
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Les 


Introduction 


Pseudo Wire Emulation Edge-to-Edge (PWE3) [RFC3985] is a mechanism to 
emulate Layer 2 services, such as Ethernet Point-to-Point circuits. 
Such services are emulated between two Attachment Circuits, and the 
Pseudowire-encapsulated Layer 2 service payload is transported via 
Packet Switching Network (PSN) tunnels between Provider Edges (PEs). 
PWE3 typically uses the Label Distribution Protocol (LDP) [RFC5036] 
or Resource Reservation Protocol - Traffic Engineering (RSVP-TE) 
[RFC3209] Label Switched Paths (LSPs) as PSN tunnels. The PEs select 
and bind the Pseudowires to PSN tunnels independently. Today, there 
is no standardized protocol-based provisioning mechanism to associate 
PWs with PSN tunnels; such associations must be managed via 
provisioning or other private methods. 


PW-to-PSN Tunnel Binding has become increasingly common and important 
in many deployment scenarios, as it allows service providers to offer 
service level agreements to their customers for such traffic 
attributes as bandwidth, latency, and availability. 


The requirements for explicit control of PW-to-LSP mapping are 
described in Section 5.3.2 of [RFC6373]. Figure 1 illustrates how 
PWs can be bound to particular LSPs. 


+------ + +------ + 

---AC1 ---|.............. PWeweddvwssese Tyk | ---Ac1--- 

---...----| PE1 | LSPs | PE2 |---...--- 

---ACn ---| |------- Links------ | | ---ACn--- 
+------ + +------ + 


Figure 1: Explicit PW-to-LSP Binding Scenario 


There are two PEs (PE1 and PE2) connected through multiple parallel 
links that may be on different physical fibers. Each link is managed 
and controlled as a bidirectional LSP. At each PE, there are a large 
number of bidirectional user flows from multiple Ethernet interfaces 
(access circuits in the figure). Each user flow utilizes a pair of 
unidirectional PWs to carry bidirectional traffic. The operators 
need to make sure that the user flows (that is, the PW-pairs) are 
carried on the same fiber or bidirectional LSP. 


There are a number of reasons behind this requirement. First, due to 
delay and latency constraints, traffic going over different fibers 
may require a large amount of expensive buffer memory to compensate 
for the differential delay at the head-end nodes. Further, the 
operators may apply different protection mechanisms on different 
parts of the network (e.g., to deploy 1:1 protection in one part and 
1+1 protection in other parts). As such, operators may prefer to 
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have a user’s traffic traverse the same fiber. That implies that 
both forwarding and reserve direction PWs that belong to the same 
user flow need to be mapped to the same co-routed bidirectional LSP 
or two LSPs with the same route. 


Figure 2 illustrates a scenario where PW-LSP binding is not applied. 


+----+ +--+ LSP1 +--+ +----+ 
+----- + PE1 |P1 | |P2| PE2 +----- + 
} [== +--+ += ----| | 
| CE1 | (emi eaiegtin See PW ul eo-dace Saved | | CE2 | 
| |---| +--+ |---| 
+-----+ | | [P3] | | +=- 
4+----+ +--+ LSP2 +----+ 


Figure 2: Inconsistent SS-PW-to-LSP Binding Scenario 


LSP1 and LSP2 are two bidirectional connections on diverse paths. 
The operator needs to deliver a bidirectional flow between PE1 and 
PE2. Using existing mechanisms, it’s possible that PE1 may select 
LSP1 (PE1-P1-P2-PE2) as the PSN tunnel for traffic from PE1 to PE2, 
while selecting LSP2 (PE2-P3-PE1) as the PSN tunnel for traffic from 
PE2 to PEL. 


Consequently, the user traffic is delivered over two disjointed LSPs 
that may have very different service attributes in terms of latency 
and protection. This may not be acceptable as a reliable and 
effective transport service to the customer. 


A similar problem may also exist in multi-segment PWs (MS-PWs), where 
user traffic on a particular PW may hop over different networks in 
forward and reverse directions. 


One way to solve this problem is by introducing manual provisioning 
at each PE to bind the PWs to the underlying PSN tunnels. However, 
this is prone to configuration errors and does not scale. 


This document introduces an automatic solution by extending 
Forwarding Equivalence Class (FEC) 128/129 PW based on [RFC4447]. 


2. Requirements Language 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 
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3; 


3. 


LDP Extensions 


This document defines a new optional TLV, the PSN Tunnel Binding TLV, 
to communicate tunnel/LSP selection and binding requests between PEs. 
The TLV carries a PW’s binding profile and provides explicit or 

implicit information for the underlying PSN Tunnel Binding operation. 


The binding operation applies in both single-segment (SS) and multi- 
segment (MS) scenarios. 


The extension supports two types of binding requests: 


1. Strict binding: The requesting PE will choose and explicitly 
indicate the LSP information in the requests; the receiving PE 
MUST obey the requests; otherwise, the PW will not be 
established. 


2. Co-routed binding: The requesting PE will suggest an underlying 
LSP to a remote PE. Upon receipt, the remote PE has the option 
to use the suggested LSP or reply to the information for an 
alternative. 


In this document, the term "tunnel" is identical to the "TE Tunnel" 
defined in Section 2.1 of [RFC3209], which is uniquely identified by 
a SESSION object that includes the Tunnel endpoint address, the 
Tunnel ID, and the Extended Tunnel ID. The term "LSP" is identical 
to the "LSP tunnel" defined in Section 2.1 of [RFC3209], which is 
uniquely identified by the SESSION object together with the 
SENDER_TEMPLATE (or FILTER_SPEC) object that consists of the LSP ID 
and the Tunnel endpoint address. 


1. PSN Tunnel Binding TLV 


The PSN Tunnel Binding TLV is an optional TLV and MUST be carried in 
the LDP Label Mapping message [RFC5036] if PW-to-LSP binding is 
required. The format is as follows: 


0 1 2 3 
01234567890123456789012345678¢9021 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


|u|F| PSN Tunnel Binding (0x0973) | Length 
Fatt ata ta tata tata tantra tanta tata ttt tata tata tatatatatatatatatat 
|c|s|tT| Unallocated flags | Reserved 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
7 PSN Tunnel Sub-TLV ~ 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 3: PSN Tunnel Binding TLV 
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The U-bit and F-bit are defined in Section 3.3 [RFC5036]. Since the 
PSN Tunnel Binding TLV is an optional TLV, the U-bit MUST be set to 1 
so that a receiver MUST silently ignore this TLV if unknown to it, 
and continue processing the rest of the message. 


A receiver of this TLV is not allowed to forward the TLV further when 
it does not know the TLV. So, the F-bit MUST be set to 0. 


The PSN Tunnel Binding TLV type is 0x0973. 


The Length field is 2 octets long. It defines the length in octets 
of the value field (including Flags, Reserved, and sub-TLV fields). 


The Flags field is 2 octets in length and three flags are defined in 
this document. The rest of the unallocated flags MUST be set to zero 
when sending and MUST be ignored when received. 


C (Co-routed path) bit: This bit informs the remote T-PE/S-PEs 
about the properties of the underlying LSPs. When set, the remote 
T-PE/S-PEs SHOULD select the co-routed LSP (as the forwarding 


tunnel) as the reverse PSN tunnel. If there is no such tunnel 
available, it may trigger the remote T-PE/S-PEs to establish a new 
LSP. 


S (Strict) bit: This bit instructs the PEs with respect to the 
handling of the underlying LSPs. When set, the remote PE MUST use 
the tunnel/LSP specified in the PSN Tunnel Sub-TLV as the PSN 
tunnel on the reverse direction of the PW, or the PW will fail to 
be established. 


Either the C-bit or the S-bit MUST be set. The C-bit and S-bit 
are mutually exclusive from each other, and they cannot be set 
in the same message. If a status code set to "both C-bit and 
S-bit are set" or "both C-bit and S-bit are clear" is received, 
a Label Release message with the status code set to "The C-bit 
or S-bit unknown" (0x0000003C) MUST be the reply, and the PW 
will not be established. 


T (Tunnel Representation) bit: This bit indicates the format of 
the LSP tunnels. When the bit is set, the tunnel uses the tunnel 
information to identify itself, and the LSP Number fields in the 
PSN Tunnel sub-TLV (Section 3.1.1) MUST be set to zero. 
Otherwise, both the tunnel and LSP information of the PSN tunnel 
are required. The default is set. The motivation for the T-bit 
is to support the MPLS protection operation where the LSP Number 
fields may be ignored. 


The Reserved field is 2 octets in length and is left for future use. 
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3.1.1. PSN Tunnel Sub-TLV 


PSN Tunnel Sub-TLVs are designed for inclusion in the PSN Tunnel 
Binding TLV to specify the tunnel/LSPs to which a PW is required to 
bind. 


Two sub-TLVs are defined: The IPv4 and IPv6 Tunnel sub-TLVs. 


0 1 2 3 

OF 2 Br Avo 67 28: 90D 2.3) 45. 68. 9308 Te 23 Ai? 6. 7 8920) 1 
tata t ata tata tata tata tata ta ta tata tata ta tata ta tata ta ta tata ta tatatat 
| Type (1) | Length | Reserved 
tata ta tata tata tae tata ta tata ta tata ta tata tata ta ta tata tata tata tatatat 
| Source Global ID | 
tata tata ta tata tata ta ta tata ta tata ta tata ta tata tata ta tata ta tata tatat 
| Source Node ID | 
tata ta tate tata ta tata ta tata ta tata ta tata tata ta tata ta tata ta tata ta tat 
| Source Tunnel Number | Source LSP Number 
tata ta tata tata tar tata ta tata ta tata ta tata tata ta ta tata tata tata tata tat 
| Destination Global ID | 
tata tata tata ta tata ta ta tata ta tata ta tata tata ta tata ta tata HMH 
| Destination Node ID | 
tata tata tata ta tar tata ta tata ta tata tata ta tata ta tata ta tata tatatata tat 
| Destination Tunnel Number | Destination LSP Number | 
tata ta tata tata ta tata tata ta ta tata ta tata ta tata tata ta tata tatatatatat 

0 1 2 3 


Figure 4: IPv4 PSN Tunnel Sub-TLV Format 


0 1 2 3 

OF De 23 a5 o Tg e OD 23 AS OP Bo OPO) 12 23) Ah. 9 ET 389. 0. 
t—+-+-4+-+-4+-4+-4+-4-4+-4-4+-4+-4-4-4+-4t-4-4-t-4+-4-4+-4+-4-4-4+-4t-4+-4+-4-4+-4 
| Type (2) | Length | Reserved 
t—+-+-4+-+-4+-4+-4+-4+-4+-4-4+-4+-4-4-4+-4t-4-4-4t-4+-4-4t-4+-4-4-4+-4t-4+-4-4-4+-4 
| Source Global ID | 
t—+-+-4+-+-4+-4+-4+-4+-4+-4-4+-4+-4-4-4+-4t-4-4-4t-4+-4-4+-4+-4-4-4+-4t-4+-4+-4-4-4 
Source Node ID z 
t—+—-+-4+-+-4+-4+-4+-4+-4+-4-4+-4+-4-4-4+-4t-4-4-4t-4+-4-4t-4+-4-4-4+-4t-4+-4-4-4-4 
| Source Tunnel Number | Source LSP Number 
t—+-+-4+-+4+-4+-4+-4+-4+-4+-4-4+-4+-4-4-4+-4t-4-4-4t-4+-4-4t-4+-4-4-4+-4t-4+-4+-4-4-4 
| Destination Global ID | 
t-+—+-4+-+-4+-4+-4+-4+-4+-4-4+-4+-4-4-4+-4t-4-4-4t-4+-4-4+-4+-4-4-4+-4-4-4+-4-4-4 
j Destination Node ID ; 
t—+-+-4+-+-4+-4+-4+-4+-4+-4-4+-4+-4-4-4+-4t-4-4+-4t-4+-4-4t-4+-4-4-4+-4t-4-4+-4-4-4 

Destination Tunnel Number | Destination LSP Number 

t—+—+-4+-+4+-4+-4+-4+-4t-4+-4-4t-4+-4-4-4+-4t-4-4-t-4+-4-4t-4+-4t-4-4+-4t-4+-4+-4-4-4 


Figure 5: IPv6 PSN Tunnel Sub-TLV Format 
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The definition of the Source and Destination Global/Node IDs and 
Tunnel/LSP Numbers are derived from [RFC6370]. This describes the 
underlying LSPs. Note that the LSPs in this notation are globally 
unique. The ITU-T style identifiers [RFC6923] are not used in this 
document. 


As defined in Sections 4.6.1.1 and 4.6.1.2 of [RFC3209], the "Tunnel 
endpoint address" is mapped to the Destination Node ID, and the 
"Extended Tunnel ID" is mapped to the Source Node ID. Both IDs can 
be either IPv4 or IPv6 addresses. The Node IDs are routable 
addresses of the ingress LSR and egress LSR of the Tunnel/LSP. 


A PSN Tunnel sub-TLV could be used to identify either a tunnel ora 
specific LSP. The T-bit in the Flags field defines the distinction 
as such that, when the T-bit is set, the Source/Destination LSP 
Number fields MUST be zero and ignored during processing. Otherwise, 
both Source/Destination LSP Number fields MUST have the actual LSP 
IDs of specific LSPs. 


Each PSN Tunnel Binding TLV MUST only have one such sub-TLV. When 
sending, only one sub-TLV MUST be carried. When received, if there 
are more than one sub-TLVs carried, only the first sub-TLV MUST be 
used, the rest of the sub-TLVs MUST be ignored. 


4. Theory of Operation 


During PW setup, the PEs may choose to select the desired forwarding 
tunnels/LSPs and inform the remote T-PE/S-PEs about the desired 
reverse tunnels/LSPs. 


Specifically, to set up a PW (or PW Segment), a PE may select a 
candidate tunnel/LSP to act as the PSN tunnel. If no candidate is 
available or none satisfy the constraints, the PE will trigger and 
establish a new tunnel/LSP. The selected tunnel/LSP information is 
carried in the PSN Tunnel Binding TLV and sent with the Label Mapping 


=i 


message to the target PE. 


Upon the reception of the Label Mapping message, the receiving PE 
will process the PSN Tunnel Binding TLV, determine whether it can 
accept the suggested tunnel/LSP or to find the reverse tunnel/LSP 
that meets the request, and respond with a Label Mapping message, 
which contains the corresponding PSN Tunnel Binding TLV. 


It is possible that two PEs request PSN Binding to the same PW or PW 


segment over different tunnels/LSPs at the same time. This may cause 
collisions of tunnel/LSPs selection as both PEs assume the active 
role. 
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As defined in (Section 7.2.1, [RFC6073]), 


into active and passive roles: 


each PE may be categorized 


1. Active PE: The PE that initiates the selection of the tunnel/LSPs 
and informs the remote PE; 


2. Passive PE: The PE that obeys the active PE’s suggestion. 


In the rest of this document, we will elaborate upon the operation 

for SS-PW and MS-PW: 

1. SS-PW: In this scenario, both PEs for a particular PW may assume 
the active roles. 

2. MS-PW: One PE is active, The PWs are 

set up using FEC 129. 


while the other is passive. 


5. PSN Binding Operation for SS-PW 


both PEs (e.g., PE1 and PE2) of a PW may 
independently initiate the setup. To perform PSN Binding, the Label 
Mapping messages MUST carry a PSN Tunnel Binding TLV, and the PSN 
Tunnel sub-TLV MUST contain the desired tunnel/LSPs of the sender. 


As illustrated in Figure 6, 


4+----+ LSP1 +----+ 
+----- + | PE1| | PE2| +----- + 
|o pel | |---| | 
CE1 | ree eS PW iota teat otay CE2 
shiz | | Zas 
tat || Pf += 
4+----+ LSP2 4+----+ 
Figure 6: PSN Binding Operation in SS-PW Environment 


As outlined previously, 


there are two types of binding requests: 


Chen, 


co-routed and strict. 


a PE (e.g., PE1) will mandate that the other PE 
(e.g., PE2) use a specified tunnel/LSP (e.g., LSP1) as the PSN tunnel 
on the reverse direction. In the PSN Tunnel Binding TLV, the S-bit 
MUST be set, the C-bit MUST be cleared, and the Source and 
Destination IDs/Numbers MUST be filled. 


In strict binding, 


Upon receipt, if the S-bit is set, as well as following the 
processing procedure defined in Section 5.3.3 of [RFC4447], the 
receiving PE (i.e., PE2) needs to determine whether to accept the 
indicated tunnel/LSP in PSN Tunnel Sub-TLV. 
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The receiving PE (PE2) may also be an active PE, and it may have 
initiated the PSN Binding requests to the other PE (PE1); if the 
received PSN tunnel/LSP is the same as was sent in the Label Mapping 
message by PE2, then the signaling has converged on a mutually agreed 
upon Tunnel/LSP. The binding operation is completed. 


Otherwise, the receiving PE (PE2) MUST compare its own Node ID 
against the received Source Node ID as unsigned integers. If the 
received Source Node ID is larger, the PE (PE2) will reply with a 
Label Mapping message to complete the PW setup and confirm the 
binding request. The PSN Tunnel Binding TLV in the message MUST 
contain the same Source and Destination IDs/Numbers as in the 
received binding request, in the appropriate order (where the source 
is PE2 and PE1l becomes the destination). On the other hand, if the 
receiving PE (PE2) has a Node ID that is larger than the Source Node 
ID carried in the PSN Tunnel Binding TLV, it MUST reply with a Label 
Release message with the status code set to "Reject - unable to use 
the suggested tunnel/LSPs", and the received PSN Tunnel Binding TLV, 
and the PW will not be established. 


To support co-routed binding, the receiving PE can select the 
appropriate PSN tunnel/LSP for the reverse direction of the PW, so 
long as the forwarding and reverse PSNs share the same route (links 
and nodes). 


Initially, a PE (PE1) sends a Label Mapping message to the remote PE 
(PE2) with the PSN Tunnel Binding TLV, with C-bit set, S-bit cleared, 
and the appropriate Source and Destination IDs/Numbers. In case of 
unidirectional LSPs, the PSN Tunnel Binding TLV may only contain the 
Source IDs/Numbers; the Destination IDs/Numbers are set to zero and 
left for PE2 to complete when responding to the Label Mapping 
message. 


Upon receipt, since PE2 is also an active PE, and may have initiated 
the PSN Binding requests to the other PE (PE1), if the received PSN 
tunnel/LSP has the same route as the one that has been sent in the 
Label Mapping message to PE1, then the signaling has converged. The 
binding operation is completed. 


Otherwise, PE2 needs to compare its own Node ID against the received 
Source Node ID as unsigned integers. If the received Source Node ID 
is larger, PE2 needs to find/establish a tunnel/LSP that meets the 
co-routed constraint, and reply with a Label Mapping message that has 
a PSN Binding TLV that contains the Source and Destination IDs/ 
Numbers of the tunnel/LSP. On the other hand, if the receiving PE 
(PE2) has a Node ID that is larger than the Source Node ID carried in 
the PSN Tunnel Binding TLV, it MUST reply with a Label Release 
message that has a status code set to "Reject - unable to use the 
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suggested tunnel/LSPs" (0x0000003B) and the received PSN Tunnel 
Binding TLV. 


In addition, if the received PSN tunnel/LSP endpoints do not match 
the PW endpoints, PE2 MUST reply with a Label Release message with 
the status code set to "Reject - unable to use the suggested 
tunnel/LSPs" (0x0000003B) and the received PSN Tunnel Binding TLV 
MUST also be carried. 


In both strict and co-routed bindings, if the T-bit is set, the LSP 
Number field MUST be set to zero. Otherwise, the field MUST contain 
the actual LSP number for the related PSN LSP. 


After a PW is established, the operators may choose to move the PWs 
from the current tunnel/LSPs to other tunnel/LSPs. Also, the 
underlying PSN tunnel may break due to a network failure. When 
either of these scenarios occur, a new Label Mapping message MUST be 
sent to notify the remote PE of the changes. Note that when the 
T-bit is set, the working LSP broken will not provide this update if 
there are protection LSPs in place. 


The message may carry a new PSN Tunnel Binding TLV, which contains 
the new Source and Destination Numbers/IDs. The handling of the new 
message should be identical to what has been described in this 
section. 


However, if the new Label Mapping message does not contain the PSN 
Tunnel Binding TLV, it declares the removal of any co-routed/strict 
constraints. The current independent PW-to-PSN Binding will be used. 


Further, as an implementation option, the PEs may choose not to 
remove the traffic from an operational PW until the completion of the 
underlying PSN tunnel/LSP changes. 

PSN Binding Operation for MS-PW 


MS-PW uses FEC 129 for PW setup. We refer to Figure 7 for this 
operation. 


+----— + LSP1 +----- + LSP2 +----- + LSP3 +----- + 
+--+ | T-PE1 | ======| S-PE1 | ======|S-PE2 | ======|T-PE2 | +--+ 
I hee | | | | | | beeen’ «| 
|CE1 | EES PA BPRS AE am a | |CE2 | 
ee es | | | | | | rece 
+--—+ |[======|  [======| 0 [====== ton 
+----- + LSP4 +----- + LSP5 -t= + LSP6. toss == + 


Figure 7: PSN Binding Operation in MS-PW Environment 
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When an active PE (that is, T-PE1) starts to signal an MS-PW, a PSN 
Tunnel Binding TLV MUST be carried in the Label Mapping message and 
sent to the adjacent S-PE (that is, S-PE1). The PSN Tunnel Binding 
TLV includes the PSN Tunnel sub-TLV that carries the desired 
tunnel/LSP of T-PE1. 


For strict binding, the initiating PE MUST set the S-bit, clear the 
C-bit, and indicate the binding tunnel/LSP to the next-hop S-PE. 


When S-PE1 receives the Label Mapping message, it needs to determine 
if the signaling is for the forward or reverse direction, as defined 
in Section 4.2.3 of [RFC7267]. 


If the Label Mapping message is for the forward direction, and S-PE1 
accepts the requested tunnel/LSPs from T-PE1, S-PE1 MUST save the 
tunnel/LSP information for reverse-direction processing later on. If 
the PSN Binding request is not acceptable, S-PE1 MUST reply with a 
Label Release Message to the upstream PE (T-PE1) with the status code 
set to "Reject - unable to use the suggested tunnel/LSPs" 
(0x0000003B) . 


Otherwise, S-PE1 relays the Label Mapping message to the next S-PE 
(that is, S-PE2), with the PSN Tunnel sub-TLV carrying the 
information of the new PSN tunnel/LSPs selected by S-PE1. S-PE2 and 
subsequent S-PEs will repeat the same operation until the Label 
Mapping message reaches to the remote T-PE (that is, T-PE2). 


If T-PE2 agrees with the requested tunnel/LSPs, it will reply with a 
Label Mapping message to initiate the binding process in the reverse 
direction. The Label Mapping message contains the received PSN 
Tunnel Binding TLV for confirmation purposes. 


When its upstream S-PE (S-PE2) receives the Label Mapping message, 
the S-PE relays the Label Mapping message to its upstream adjacent 
S-PE (S-PE1), with the previously saved PSN tunnel/LSP information in 
the PSN Tunnel sub-TLV. The same procedure will be applied on 
subsequent S-PEs, until the message reaches T-PE1 to complete the PSN 
Binding setup. 


During the binding process, if any PE does not agree to the requested 
tunnel/LSPs, it can send a Label Release Message to its upstream 
adjacent PE with the status code set to "Reject - unable to use the 
suggested tunnel/LSPs" (0x0000003B). In addition, if the received 
PSN tunnel/LSP endpoints do not match the PW Segment endpoints, the 
receiving PE MUST reply with a Label Release message with the status 


code set to "Reject - unable to use the suggested tunnel/LSPs" 
(0x0000003B) and the received PSN Tunnel Binding TLV MUST also be 
carried. 
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9. 


9. 


For co-routed binding, the initiating PE (T-PE1) MUST set the C-bit, 
reset the S-bit, and indicate the suggested tunnel/LSP in the PSN 
Tunnel sub-TLV to the next-hop S-PE (S-PE1). 


During the MS-PW setup, the PEs have the option of ignoring the 
suggested tunnel/LSP, and to select another tunnel/LSP for the 
segment PW between itself and its upstream PE in reverse direction 
only if the tunnel/LSP is co-routed with the forward one. Otherwise, 
the procedure is the same as the strict binding. 


The tunnel/LSPs may change after a MS-PW has been established. When 
a tunnel/LSP has changed, the PE that detects the change SHOULD 
select an alternative tunnel/LSP for temporary use while negotiating 
with other PEs following the procedure described in this section. 


PSN Tunnel Select Considerations 


As stated in Section 1, the PSN tunnel that is used for binding can 
be either a co-routed bidirectional LSP or two LSPs with the same 
route. The co-routed bidirectional LSP has the characteristics that 
both directions not only cross the same nodes and links, but have the 
same life span. But for the two LSPs case, even if they have the 
same route at the beginning, it cannot be guaranteed that they will 
always have the same route all the time. For example, when Fast 
ReRoute (FRR) [RFC4090] is deployed for the LSPs, link or node 
failure may make the two LSPs use different routes. So, if the 
network supports co-routed bidirectional LSPs, it is RECOMMENDED that 
a co-routed bidirectional LSP should be used; otherwise, two LSPs 
with the same route may be used. 


Security Considerations 


The ability to control which LSP is used to carry traffic from a PW 
can be a potential security risk both for denial of service and 
traffic interception. It is RECOMMENDED that PEs not accept the use 
of LSPs identified in the PSN Tunnel Binding TLV unless the LSP 
endpoints match the PW or PW segment endpoints. Furthermore, it is 
RECOMMENDED that PEs implement the LDP security mechanisms described 
in [RFC5036] and [RFC5920]. 


IANA Considerations 
1. LDP TLV Types 
This document defines a new TLV (Section 3.1) for inclusion in the 


LDP Label Mapping message. IANA has assigned TLV type value 0x0973 
from the "LDP TLV Type Name Space" registry. 
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9.1.1. PSN Tunnel Sub-TLVs 


This document defines two sub-TLVs (Section 3.1.1) for the PSN Tunnel 
Binding TLV. IANA has created a new PWE3 subregistry titled "PSN 
Tunnel Sub-TLV Name Space" for PSN Tunnel sub-TLVs and has assigned 
Sub-TLV type values to the following sub-TLVs: 


IPv4 PSN Tunnel sub-TLV - 1 
IPv6 PSN Tunnel sub-TLV - 2 
In addition, the values 0 and 255 in this new registry should be 
reserved, and values 1-254 will be allocated by IETF Review 
[RFC5226]. 
9.2. LDP Status Codes 
This document defines two new LDP status codes, IANA has assigned 
status codes to these new defined codes from the "LDP Status Code 
Name Space" registry. 
"Reject - unable to use the suggested tunnel/LSPs" - 0x0000003B 
"The C-bit or S-bit unknown" - 0x0000003C 
The E bit is set to 1 for both new codes. 
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